Про стандартизацию ФСТЭК и сертификацию процессов безопасной разработки

Помните один из первых постов этого канала? https://www.tg-me.com/DevSecOps Wine/com.sec_devops/20 Отечественная стандартизация безопасной разработки продолжает набирать обороты. В пятницу ФСТЭК России опубликовал на regulation.gov Порядок сертификации процессов безопасной разработки программного обеспечения средств защиты информации :

https://regulation.gov.ru/Regulation/Npa/PublicView?npaID=143132

Главная идея, стоящая за проектом проста. Примирить требования регуляторики и Agile. Позволить разработчикам не отправлять каждый релиз на согласование в испытательную лабораторию, а доказав надежность своей CI/CD и пройдя её сертификацию, утверждать - что все продукты этой сертифицированной CI/CD заслуживают доверия.

Цитата из пояснительной записки к проекту:

"Сертификация процессов безопасной разработки программного обеспечения средств защиты информации является добровольной и позволит разработчикам и производителям сертифицированных средств защиты информации в случае проведения данной сертификации проводить испытания средств защиты информации, обусловленные внесением изменений в программное обеспечение средства защиты информации, самостоятельно без привлечения испытательной лаборатории. Что позволит сократить сроки проведения испытаний и затраты разработчиков и производителей сертифицированных средств защиты информации на проведение указанных испытаний средств защиты информации и, как следствие, снизить себестоимость средств защиты информации, применяемых в государственных информационных системах и на объектах критической информационной инфраструктуры."

Какое это имеет отношение к широкому рынку? Очень простое. Несмотря на определенные в документе границы (сертификация средств защиты), аналогичные подходы могут быть спроецированы и на обычные приложения. На компании не являющиеся разработчиками антивирусов, межсетевых экранов и иных специализированных средств.

В частности с февраля 2022 года Банк России в последней редакции своего Профиля защиты*, в разделе 7.4 рассказывает о требованиях к безопасности жизненного цикла. По мнению регулятора (оставим за скобками ряд правовых и технических нюансов) это позволяет избежать оценок соответствия или сертификации каждого релиза ДБО, т.е. по целям является аналогичным проекту ФСТЭК:

https://www.cbr.ru/content/document/file/132666/inf_note_feb_0422.pdf

*Профиль защиты является де-факто стандартом требований регулятора к банковским ДБО, личным кабинетам финансовых организаций, другим приложениям, связанным с финансовыми операциями (не являющимися средствами защиты по ФСТЭК России).

#dev #ops #law

#Конференция #CoopDays

Прямо сейчас в прямом эфире третья конференция Coop-Days. В программе доклады посвящённые не только AppSec и DevSecOps, но и выступления на темы построения карьеры в ИБ, процессного управления и перспектив развития искусственного интеллекта.

Прямая трансляции доступна по ссылке: https://youtu.be/E2__QfNtwwI (будет доступна в записи).

Программа конференции в сообщении ниже.

В эти дни проходит конференция Coop-Days 2023, организованная компанией «РАД КОП». Сегодня в повестке доклады по ИТ и ИБ.

Ознакомиться с программой и посмотреть трансляцию можно по ссылке на сайте культурно-просветительского центра АРХЭ.

Докладчики уже выступают, присоединяйтесь, будет интересно!

Трансформирует ли AI работу AppSec и DevSecOps?

В непрерывном потоке новостей об очередных чудо-помощниках или подборках GPT-агентов можно не заметить самой важной проблемы, связанной с AI. Изначально проблематика DevSecOps и современного AppSec, встроенного в CI/CD, возникла из условий рыночной гонки компаний за клиентами. Когда перед организациями встала необходимость быстрее адаптировать приложения к потребностям пользователей и бороться за их внимание и деньги. Ускорять изменения. Обеспечивать сверхбыстрое масштабирование проектов без потери надежности. Это в свою очередь породило потребности в новых инструментах и подходах к работе. Распространились контейнеры и их оркестраторы, набрали популярность low-code платформы и облачные сервисы.

Но все это развивается столь стремительно, что количество накапливающихся ошибок и проблем непрерывно возрастает. А все более сложная экосистема сервисов, инструментов, утилит, фреймворков, стеков технологий - порождают все большее количество сбоев, инцидентов, ошибок, необходимости интеграций, настроек и... дефицит кадров, способных разобраться в этом хаосе. В итоге наша дисциплина превращается в разновидность "алхимии". Когда дефицитные "жрецы безопасного кода" ценятся так сильно, что джуниор с полугодовым опытом работы вполне может претендовать на вакансию 150к netto с удаленкой из региона, а грамотные инженеры с стажем 5+ считаются "прожженными ветеранами" и ценятся как "крыло от боинга".

И это не досужие домыслы, а суровые факты действительности, подтверждаемые статистикой. Например, созданный в 2010 году Consortium for Information & Software Quality (CISQ) оценивает ущерб от некачественного кода и недостатков процессов разработки в 2022 году в 2,41 триллион долларов, а дефицит ИТ-кадров в 300 тысяч человек, и это только в США. Подробнее о результата исследования можно почитать здесь . Но очевидно, что если в развитых с точки зрения ИТ разработки США существуют такие проблемы, то аналогичная ситуация (или хуже) характерна для всего мира, особенно для развивающихся регионов вроде Африки*.

Казалось бы - отличные новости, и впереди много работы. Но тут на сцену выходит AI, который может оказаться фактором существенных и достаточно быстрых изменений в индустрии (буквально на горизонте 3-5 лет). Что-то похожее происходило с классическими веб-дизайнерами, очень востребованными в конце нулевых, но существенно утратившими позиции после появления различных конструкторов а-ля Figma. Или консервативными сисадминами, оттесняемыми на периферию облачными технологиями и виртуализацией. Конечно, это не означает, что веб-дизайнеры или сисадмины "вымерли". Среди них существуют отдельные супер-востребованные гуру, у которых все хорошо. Остаются и середняки. Просто меняется уровень востребованности и падают заработные платы.

И если мы смотрим на такие массовые тренды, то должны задуматься о том, а что будет дальше? Каким инструментарием необходимо овладеть, чтобы быть востребованным и соответствовать актуальному уровню компетенций? И тут нейронные сети с различными специализациями, интегрированные в единое целое с помощью специальных оболочек, позволяющих использовать предустановленные промпты - кажется являются следующей вехой развития индустрии. Они не только помогают автоматизировать типовые задачи, и оказываются встроенными крупными корпорациями в свои сервисы и инструменты "из коробки". Но и снимают существенную часть аналитической нагрузки с опытных специалистов. Заменяя как отдельные роли и направления работы, так и толковых джунов, быстрее и точнее собирая необходимую информацию. Автоматизируя рутинные и хорошо стандартизуемые операции.

Здесь очень характерно поведение Microsoft, который после покупки GitHub, начал интегрировать с ним все больше интересных инструментов, связанных с безопасностью разработки. Например, уже в декабре на базе GitHub должен открыться (если еще не открылся) чат с Copilot, который позволит в числе прочих фич следить за безопасностью создаваемого кода в режиме онлайн. А тут можно посмотреть демо от CEO Microsoft с возможностями Copilot в части интеграции с различными приложениями и внешними источниками данных, в рамках Office 365 и как это позволит автоматизировать самые разные задачи. И это один продукт, одной корпорации, не специализированной на кибербезопасности. Понятное дело, что Microsoft известен своими багами и что в любом случае адаптация к новым возможностям займет какое-то время. Но кажется для всех, кто хочет "держать хвост по ветру" наступает время готовиться к адаптации прямо сейчас. И для тех, кто любит неопределенность и риски открываются возможности по развитию собственных стартапов в новых нишах. Например, почти наверняка потребуются консультанты по обучению команд AppSec и DevSecOps использованию и внедрению нового инструментария, возникнет потребность в защите API агентов GPT, встанут вопросы дообучения и тюнинга моделей, появятся истории про доверие и конфиденциальность вводимых данных, станет накапливаться ещё больше чисто юридических кейсов относительно прав собственности на "выделяемый AI продукт", потребуются стандарты и фреймворки безопасности AI и т.д. и т.п.

И хотя футурология и прогнозы дело не благодарное** (во многом потому, что технологии не существуют в вакууме и многое зависит от сил, занимающихся их внедрением, и заинтересованности субъектов, которые используют эти технологии), кажется, что AI не будет пустым хайпом и в ближайшую декаду мы увидим существенную трансформацию профессии, к которой можно и нужно готовиться прямо сейчас. А что думаете вы?

*Подробнее о состоянии безопасности в развивающихся странах можно посмотреть в замечательном выступлении Евгения Соболева: https://youtu.be/XWSrDseKMaI?si=QStWhX4u3BfSNlUp

**Здесь "на каникулы" рекомендую годную книгу "ИИ-2041. Десять образов нашего будущего" Кай-Фу Ли и Чэнь Цюфань - достаточно взвешенная и многомерная аналитика от профильного специалиста на тему влияния AI на разные области жизни. Сама книга смесь сборника художественных рассказов и научно-популярных заметок к каждому из них, где рассматриваются в том числе аспекты кибербезопасности AI.

#dev #ops #ai #прогнозы

SSPM и защита SaaS сервисов

В развитии вчерашнего лонгрида пример нового класса решений, ещё не сильно распространенного на рынке. SSPM призваны решать проблему контроля и безопасности интеграций компаний со все большим количеством облачных сервисов. Когда тот же самый GPT помощник, или онлайн-репозиторий не просто детектируется, но ставится на непрерывный контроль автоматически. Это подразумевает:

- правильную конфигурацию;
- выявление уязвимостей;
- мониторинг и реагирование на инциденты;
- контроль утечек защищаемой информации;
- управление привилегиями;
и многое другое

Подробнее про риски, подходы и модель работы с SaaS здорового человека можно почитать в прилагаемом отчете AppOmni - одного из вендоров SSPM. По данным авторов отчета в части безопасности SaaS на рынке доминирует ложная уверенность в надежности собственной системы защиты. Так 71% из 644 опрошенных оценивают уровень безопасности своих SaaS между средним и высоким, при том, что 79% из них сталкивались с соответствующими инцидентами за последние 12 месяцев. При этом, большинство опрошенных занимаются ручным контролем интеграции SaaS в организацию, и не осуществляют непрерывный контроль текущего состояния сервисов. Число же используемых сервисов и интеграций непрерывно растет.

Здесь очень хорошо видна коренная проблема ИБ: непрерывное развитие технологий и гонка за новыми интеграциями порождает небезопасный фронтир, который требует автоматизации. Автоматизация требует инвестиций времени и квалификации, либо деньги и сторонние решения с поддержкой. И вот уже на смену универсальным сканерам, IaC утилитам и system hardening решениям приходят "точечные продукты" под узкопрофильные задачи. Так и живем.

#ops #sspm #решение

Всем, привет! Мы выходим из зимней спячки с хорошими новостями.

Меньше месяца осталось до специализированной конференции по безопасности контейнерных приложений и контейнерных сред - БеКон 2024.

Дата: 5 июня
Место: Москва, LOFT HALL#2

В этом году на конференции обсудим вопросы:
- Management/organization - зачем отдельная команда по безопасности K8s ?!
- Cluster security - настроим правильным образом сбор Kubernetes Audit Log и окунемся для харденинга в Linux user namespace.
- Image security - как исправить ситуацию с образом приложения если он полное дно и как там поживают антивирусы для образов.
- Network security - разберемся что под капотом у новых реализаций Service Mesh и как они вообще помогают ИБ.
- Secret management - не очевидные способы управления секретами, которые могут дать фору остальным подходам.
- Multitenancy - какие есть варианты и какие у них сильные и слабые стороны.

Билеты можно приобрести тут, а выиграть в конкурсе и пойти бесплатно - вот так 😉

P.S. Что и как было в прошлом году можно почитать здесь, материалы доступны онлайн (слайды, видео). Аналогично до конца лета планируется выкладка в открытый доступ материалов 2024 года.

#event #инфо

AI-Driven Threat Modelling with GPT

Сегодня в центре внимания проект STRIDE GPT — инструмент для моделирования угроз с помощью AI. В качестве ввода инструмент принимает описание приложения в свободной форме и несколько параметров, таких как аутентификация и классификация приложения. В результате инструмент выдает угрозы по методологии STRIDE, рекомендации, граф attack tree и тестовые кейсы. STRIDE GPT можно развернуть локально или запустить через веб-интерфейс.

В основе проекта лежит OpenAI Platform и несколько небольших скриптов на Python. Для работы со STRIDE GPT требуется OpenAI токен аккаунта с положительным балансом (оплата производится отдельно от ChatGPT в зависимости от количества отправленных запросов в API). Все промпты можно посмотреть там же в скриптах. Красивые графы attack tree генерируются с помощью визуализации Mermaid, которая интерпретирует и отображает схемы, сгенерированные GPT. Специально обученной модели для моделирования угроз здесь нет. Вместо OpenAI можно использовать Google AI, Mistral AI или Azure OpenAI service.

Конечно, результат работы можно получить, используя пользовательский аккаунт ChatGPT и без Python-скриптов, однако, если ознакомиться с целями инструмента из презентации, становится ясно, что две из них направлены на повышение знаний экспертов, не связанных с безопасностью. Таким образом, если в организации используется, например, Azure OpenAI для внутренних нужд, то команда AppSec может предоставить красивый интерфейс STRIDE GPT тем же разработчикам, который будет выдавать ожидаемый и в целом устраивающий результат для повышения уровня осведомленности и культуры безопасности.

Можно дописать интеграцию с отечественными аналогами вроде YandexGPT и использовать в РФ 😃

А как вы относитесь к использованию подобных технологий в рамках собственных проектов? Давайте соберем немного опыта и мудроты в комментариях.

Еще немного полезных ссылок на тему AI и TM:

Threat Modeling Example with ChatGPT

More on GPT-3 and threat modeling

Leveraging LLMs for Threat Modeling - GPT-3.5 vs Claude 2 vs GPT-4

DiagramGPT

#threatmodeling #ai

Siren by Open Source Security Foundation (OpenSSF)

Те, кто давно подписан на канал, помнят проект OpenSSF, о котором здесь неоднократно писалось. Наши любимые проекты – это Scorecard и Insights. Недавно они выпустили новый мини-проект Siren, Open Source Threat Intelligence. Это рассылка писем о последних техниках и IOC, связанных с атаками на open-source проекты. Инструмент появился логично спустя месяц после атак на xz-utils.

По словам OpenSSF, эффективность таких TI ресурсов, живущих за счет сообщества, подтверждается проектами oss-security mailing list и (linux)-distros. И понятно почему так происходит - это ключевая фича сообществ и open source, про которую написана замечательная "Социальная Архитектура: Создание онлайн сообществ" П. Хинченса (русский перевод доступен по ссылке: https://irus.github.io/social-architecture-ru/ ).

Интересно, что именно будет попадать в данную рассылку и какая будет частота оповещений? Подписались, посмотрим. Тот же DataLog, например, собрал только датасет из 1500 вредоносных PyPI и NPM пакетов меньше чем за 2 года с помощью своего open-source инструмента GuardGod. Они же недавно писали про вредоносные PyPI пакеты, которые атаковали MacOS машины месяц назад...

#supplychain

Как мы взломали многомиллиардные компании за 30 минут с помощью поддельного расширения VSCode 😇

Тема supply chain не имеет конца и края. Сегодняшний пост мы начнем со статистики о плагинах VS Code:

- 1,283 расширений VS Code содержат известные вредоносные зависимости, с общим числом установок 229 миллионов.
- 87 расширений пытаются прочитать файл /etc/passwd на хост-системе.
- 8,161 расширений общается с жестко закодированным IP-адресом.
- 1,452 расширений запускают неизвестные исполняемые файлы или DLL.
- 145 расширений были отмечены VirusTotal с высокой степенью уверенности.
- 2,304 расширений используют репозиторий другого издателя на GitHub.

Такой статистикой поделились авторы сервиса ExtensionTotal по проверке безопасности плагинов VS Code в своей серии статей (часть 1, часть 2).

А теперь пара слов, почему так происходит:

- Стать "проверенным" издателем на VSCode Marketplace можно, просто подтвердив домен.
- Можно связать любое репо на GitHub с вашей страницей расширения, даже если оно вам не принадлежит.
- Расширения могут выполнять произвольный код, создавать процессы, выполнять системные вызовы, импортировать любые пакеты NodeJS.
- Расширения автоматически обновляются, что позволяет атакующему вставить вредоносный код после роста популярности плагина.

В частности, авторы статей разместили копию популярного плагина Darcula. В результате за сутки плагин вывелся в топы, а авторы получили пинги от крупных компаний, чьи имена не раскрыли. Скорее всего, речь идет о техногигантах вроде Microsoft, Google, Apple, Amazon.

Таким образом, "потоп" продолжается и по мере усложнения экосистем и зависимостей количество "сценариев провала" возрастает. Полностью закрыть возникающие потребности в информационной безопасности не может ни автоматизация, ни искусственный интеллект, ни развитие новых образовательных подходов. Времени, технологий и рук решительно не хватает. Подробнее об этом в нашем материале на соседнем канале:

https://www.tg-me.com/radcop_online/138

Интересно, когда появятся сервисы по сканированию плагинов для кофеварок и плоек? 😁

#supplychain

State of Exploitation - A Peek into the Last Decade of Vulnerability Exploitation

Я думаю, что ни для кого не секрет, что число уязвимостей с каждым годом только растет. VulnCheck выпустил неутешительную статистику по данному тренду с 2014 по 2024 год:

- Число CVE с известной эксплуатацией увеличивается на 19,7% в год.
- Число раскрытых CVE растет на 14,1% в год.
- Число CVE с публично доступными Proof-of-Concept (PoC) эксплойтами растет на 11,8% в год.

При этом:

31% уязвимостей имеют PoC, но только 1% уязвимостей эксплуатируется в "живой природе".

В данном канале мы также не освещали существующие проблемы NIST и их неспособность обрабатывать очередь из необработанных CVE для добавления в NVD. К февралю таких уязвимостей насчитывалось 11 000, на фоне сокращения бюджета и ухода текущего ключевого подрядчика CISA. К счастью, если вы еще не слышали, месяц назад NIST объявили, что к сентябрю этого года проблема будет решена, так как найден новый подрядчик. История с NVD с самого начала вызвала сильный резонанс. Были даже слышны упоминания о потенциальном "конце света" в мире управления уязвимостями.

На фоне этого хочется поделиться статьей "Dirty Little Secrets of Vulnerability Management". Автор освещает общепринятые мифы управления уязвимостями. В частности, он напоминает, что NVD не является единственным источником CVE. Существует 383 партнёра программы CVE, поддерживающих приём и регистрацию CVE (так называемые CVE Numbering Authority). Среди них есть не только вендоры, такие как Apple, но и независимые исследователи, open source и bug bounty площадки. И даже если вам это не подходит, существуют китайские аналоги CNNVD, число уязвимостей которых превышает NVD, и российская БДУ ФСТЭК🙈. Кстати, про проблему NVD и особенности БДУ подробно осветил Александр Леонов в своём докладе phd2.

#vm #cve

OWASP Authoritative Guide to SBOM

Как может показаться из названия документа, речь пойдет об SBOM (software bill of materials), хотя, на самом деле, документ о многогранном и необъятном использовании BOM и CycloneDX (стандарт OWASP для supply chain). Да, здесь есть и про формат BOM, и про применении в SDLC на разных стадиях, но большинство внимания уделено все же сценариям использования.

Чем это может быть полезно лично для вас и вашей организации? Стандарт затрагивает такие темы как:

- Управление конфигурациями предприятия (CMDB): Отслеживание активов и управление конфигурациями в базе данных.
- Проверка целостности: Обеспечение того, что компоненты программного обеспечения не были изменены с момента их выпуска.
- Аутентичность: Подтверждение подлинности компонентов или самого SBOM.
- Анализ устаревших компонентов: Определение компонентов, которые больше не поддерживаются или устарели.
- Происхождение (Provenance): Отслеживание истории и происхождения компонентов.
- Родословная (Pedigree): Представление информации о происхождении, изменениях и вариациях компонентов.
- Управление поставщиками и рисками: Оценка и управление рисками, связанными с поставщиками и их продукцией.
- Управление цепочкой поставок: Оптимизация процессов управления поставками программных компонентов.
- Полнота состава и "известные неизвестные": Оценка полноты информации в BOM и идентификация элементов с неизвестным статусом.
- Подтверждение и проверка состава: Проверка точности и полноты информации о составе продукта на всех этапах его жизненного цикла.
- Управление криптографическими активами: Управление и отслеживание криптографических ключей, сертификатов и других элементов.
- Идентификация слабых криптографических алгоритмов: Определение и замена устаревших или уязвимых криптографических алгоритмов.
- Готовность к постквантовой криптографии (PQC): Подготовка к эре постквантовых вычислений и обеспечение безопасности криптографических систем перед лицом новых угроз.

Кстати, на сайте Белого Дома в указе от 2021 года о повышении безопасности нации указано о необходимости создания SBOM для всех критически важных программных продуктов, используемых правительственными агентствами. Это далеко не первое упоминание SBOM правительством США. Самое раннее упоминание SBOM можно найти в «Cyber Supply Chain Management and Transparency Act» от 2014 года. В целом подобная документация позволяет отлично понять "куда копать дальше" тем, кто остается работать в РФ и уже выполнил базовые задачи в рамках тематики КИИ и хочет "порешать задачи под звездочкой".

#sbom #owasp

The Open Source Problem

Мы в канале любим статистику, особенно если она хорошо раскрывает глобальные проблемы на примере громких инцидентов. Недавно нам попался интересный ресерч: автор которого взял 5000 pip-пакетов и применил к ним "критерии Цзя Тан", того самого китайского контрибьютора бекдора в xz. Набор критериев простой: права на коммит, китайский часовой пояс и email, в котором сочетается имя и номер. В результате получилось 310 pip-пакетов. Даже у контрибьютеров самого pip есть некий [email protected], соответствующий таким критериям. Дополнительно можно почитать здесь и здесь.

А теперь взглянем на статистику Blackberry из их отчета о безопасности цепочки поставок ПО, составленного по результатам опроса 1000 старших руководителей:

- 51% компаний смогли восстановиться после взлома в течение недели, около 40% потребовалось месяц.
- 74% атак исходили от участников цепочки поставок программного обеспечения, о которых компании не знали или не отслеживали до взлома.
- Хотя 78% компаний отслеживают влияние атак на цепочку поставок, только 65% информируют своих клиентов об этих инцидентах.

Учитывая, что трактовать и ту и другую статистику можно по-разному, выводы делайте сами.

Мы, в свою очередь, подбросим очередную новость о том, как в популярный проект polyfill.js китайцы внедрили вредоносный код на 100k+ сайтов. Здесь, правда, история о том, как развивалась атака, более загадочная, ибо домен и GitHub-репозиторий были переданы китайским мейнтейнерам в феврале этого года одним из разработчиков polyfill, принадлежащей компании Fastly. Поясняем: один из рядовых разработчиков компании, которой принадлежит проект polyfill, просто взял и продал проект новым владельцам (за что, скорее всего, получил хорошие деньги). Есть semgrep правило для поиска и замены вредоносных пакетов. Вот также полезный свежий ресерч.

#supplychain

Enhancing Automated Configuration Security Capabilities with OpenAI Grant Funding

OpenAI рассказала о 8 программах получивших грант Cybersecurity Grant Program, направленный на финансирование активностей по улучшению методик защиты с помощью AI. Здесь есть защита LLM от prompt-инъекций, использование AI для OSINT, автоматизация red team и тд.

Нам лично понравился и показался релевантным к каналу проект CoGuard. В исследовании команда CoGuard продемонстрировала использование OpenAI API для решения проблемы неправильной настройки ПО.

Основные этапы включали:

- С использованием LLM из документации по ПО извлекались параметры, важные с точки зрения безопасности.
- Для каждого параметра определялись его стандартное и рекомендуемое с точки зрения безопасности значения.
- Полученная информация трансформировалась в правила, которые могут быть использованы сканерами конфигураций для проверки безопасности настроек.

Использование LLM позволило автоматизировать и упростить добавление новых правил и поддержку актуальных конфигураций, значительно повышая эффективность процессов разработки и обслуживания программного обеспечения.

А еще у Cougard есть open-source тула для сканирования конфигурации внутри docker-образов и облачных ресурсов. Среди поддерживаемых Kafka, Tomcat, Kubernetes, MongoDB, MySLA, nginx , postgesql, helm, elasticsearch и другие.

#configuration #ai

В продолжении понедельничного поста...

#Юмор

OWASP Dep-scan

В чате участники нашего сообщества поделились проектом Dep-scan — инструментом поиска уязвимостей в зависимостях "нового поколения" от OWASP. Несмотря на то что инструмент не новый, известен он не так сильно как Dependency-Check и Dependency-Track.

Отличительная особенность данного инструмента — это предоставление возможности по приоритизации уязвимостей. Dep-scan добавляет к каждой уязвимости графу "Insights". Приоритизация осуществляется за счет так называемого Reachability анализа — анализа кода на предмет того, может ли уязвимый пакет быть затронут опасными методами, например, пользовательским вводом с помощью параметров requests или методов safecode. Механизм построен на базе проекта Atom и поддерживает Java, JavaScript, TypeScript и Python.

В проект также добавили режим аудита риска. Этот режим позволяет оценить степень рискованности npm или PyPI-пакетов с помощью заложенной разбивки весов. Баллы риска могут прибавляться, например, если у пакета всего два npm-пользователя, приватный пакет доступен в публичном реестре (привет атаки dependency confusion), либо пакет в принципе достаточно старый.

Среди фич авторы отмечают генерацию SBOM за счет интеграции с cdxgen, быстроту сканирования и количество поддерживаемых языков и форматов (Node.js, Java, PHP, Python, Go, .NET, C/C++, Docker, OCI image, YAML).

А какие SCA используете вы? И есть ли положительный опыт работ с импортозамещенными инструментами? Обсуждаем в комментариях и чате.

#sca

*И иллюстрация к предыдущему посту